The following abbreviations are herewith defined, at least some of which are referred to within the following description of the prior art and the present invention.
3GPP 3rd Generation Partnership Project
A-GW Access Gateway
CDMA Code Division Multiple Access
CS Circuit Switched
EPS Evolved Packet System
E-UTRAN Evolved-UMTS Radio Access Network
GAN Generic Access Network
GANC Generic Access Network Controller
GERAN GSM EDGE Radio Access Network
GSM Global System for Mobile Communications
HO Handoff
HSS Home Subscriber Server
IMS IP Multimedia Subsystem
IP Internet Protocol
IP-CAN IP-Connectivity Access Network
LTE Long-Term Evolution
NAS Non Access Stratum
MSC Mobile Switching Centre
MME Mobile Management Entity
PCEF Policy and Charging Enforcement Function
PDN-GW Packet Data Network-Gateway
PCRF Policy and Charging Rules Function
PS Packet Switched
PSTN Public Switched Telephone Network
QCI Quality of Service Class Identifier
RRC Radio Resource Control
SGSN Serving GPRS Support Node
SIP Session Initiated Protocol
SRVCC Single Radio Voice Call Continuity
TAU Tracking Area Update
UE User Equipment
UMTS Universal Mobile Telecommunications System
UTRAN UMTS Radio Access Network
VoIP Voice Over Internet Protocol
WCDMA Wideband Code Division Multiple Access
In 3GPP there are currently several different solutions that can be used to support a voice service via EPS (Evolved Packet System). One solution is IMS MMTel which might have to use the SRVCC (Single Radio Voice Call Continuity) solution if there are no VoIP radio bearers in the whole wide area network. The SRVCC solution targets supporting IMS Voice with a mechanism to move to the accesses GSM, WCDMA, or cdma2000 1xRTT and continue to support the voice service using a CS service bearer thus performing a handover from the PS domain (EPS) to the CS domain. FIG. 1 (PRIOR ART) is a diagram of an architecture which illustrates the SRVCC solution described in 3GPP TS 23.216 v. 8.1.0, “Single Radio Voice Call Continuity (SRVCC)” Sep. 24, 2008 (the contents of which are incorporated herein by reference). Another solution is CS Fallback in which the user is registered in the CS domain even when he/she is on the LTE PS only access and when the use receives or makes a CS call his/her terminal is moved over to a radio technology that supports CS service (GSM, WCDMA, or cdma2000 1xRTT). The terminal has fallen back to CS. FIG. 2 (PRIOR ART) is a diagram of an architecture which illustrates the CS Fallback solution described 3GPP TS 23.272 v. 8.1.0, “Circuit Switched Fallback in Evolved Packet System” Sep. 24, 2008 (the contents of which are incorporated herein by reference).
Furthermore, there are several industry initiatives which are trying to improve the CS Fallback solution by re-using some of the SRVCC mechanisms. One current industry initiative known as CSoLTEvGAN proposes to tunnel the CS service over IP and this solution is built upon the GAN standard described in TS 43.318 v.6.12.0 Generic Access Network (GAN); Stage 2 Jun. 16, 2008 (the contents of which are incorporated herein by reference). To bring the CSoLTEvGAN solution into 3GPP standardization (or to simply ensure that the terminal support for the CSoLTEvGAN solution is not misunderstood by the network as the SRVCC solution) requires an extension to the terminal capability. The extended terminal capability would indicate that the UE is either to be “SRVCC capable” or “CSoLTEvGAN capable” (or both). This is already known by some companies in the industry initiative. However, even with this extended terminal capability there is still a problem that can occur due to the co-existence of different solutions like the SRVCC solution and the CSoLTEvGAN solution. This problem which is described in detail below occurs when a terminal that supports both “SRVCC” and “CSoLTEvGAN” has an active voice session and there needs to be a handoff when the terminal moves from the coverage area of an E-UTRAN to the coverage area of a GERAN/UTRAN.
To support HO in the CSoLTEvGAN solution, the SRVCC mechanisms would be re-used in such a way that the terminal (herein also denoted UE) would fake the SRVCC capability by means of telling the network (in particular the MME) upon attachment that it is an SRVCC capable UE. This would make the MME and eNodeB (both EPS nodes) believe that the terminal is capable of the SRVCC solution. As such, when the terminal which has an active voice session leaves the E-UTRAN to a GERAN/UTRAN then the eNodeB would signal that a certain handover request sent to the MME is an SRVCC handover (or that the target cell capability does not support IMS Voice (or VoIP in general)—which option is not decided by 3GPP yet). The MME would use the information from the eNodeB together with the terminal capability to decide whether or not the “bearer splitting function” and the Sv interface (both defined for SRVCC) would be used or not.
The Sv interface in the CSoLTEvGAN solution would be between the MME and the GANC. However, the Sv interface in the SRVCC solution is between the MME and the MSC (or MSC Server). Consequently, in the case where both the CSoLTEvGAN and IMS Voice (requiring SRVCC) are to be supported, the MME cannot decide which node it shall signal to use the Sv interface procedures to handoff of the active voice session of the terminal. FIG. 3 (PRIOR ART) is a diagram of an architecture where both the SRVCC solution and the CSoLTEvGAN solution exist but there is a problem in which the MME 300 does not know which node (MSC 302 or GANC 304) to direct the handoff signaling when the terminal 306 which supports both “SRVCC” and “CSoLTEvGAN” has an active voice session with the GANC 304 moves from an E-UTRAN 308 to a GERAN/UTRAN 310. Accordingly, there has been and is a need to address this shortcoming to support the co-existence of the SRVCC solution and the CSoLTEvGAN solution. This need and other needs are satisfied by the present invention.